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(54) Dynamically determining network media type 

(57) A method for dynamically determining a media 
type of a local area network (LAN) to which a network 
device is connected. A network interface driver software 
module is executed which is the lowest level of software 
to communicate with the LAN and which handles the 
sending and receiving of communication packets to and 
from the LAN by appending or stripping off packet frame 
headers . The network interface driver software module 
has one or more logical boards for processing commu- 
nication packets havMgi&jfer^n^ 
and has one or more configuration tables , each respect 
tft&Jv^s^acj^ e^ boards, which 

each include a frame type identifying value that identi- 
fies a combination of frame type and media type for 
packets processed by the corresponding logical board. 
The network interface driver software module also has 
a service routine which can be accessed via an entry 
point. One or more protocol stack modules are executed 
for processing packe tsJLhaXusej^^ 
tocols. and a multiplexer software module is executed 
which interfaces between the network interface driver 
software module and the one or more protocol stack 
modules and which routes packets f rom the network in- 
terface driver software module to the respective protoco l 
stack modules according to the protocol used bv the 
packets. The entry point of the network interface driver 
service routine is obtained via the multiplexer module. 
A location of one of the configuration tables is then ob- 
tained via the service routine. The frame type identifying 
value in the one configuration table is then read, and the 
network media type is determined by comparing the 
frame type identifying value read from the one configu- 
ration table to one or more values that correspond to a 
predetermined media type. 
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Description 

The present invention concerns a network interface device by which the functionality of a peripheral is made avail- 
able to users of a computerized local or wide area network. More particularly, the present invention is a network interface 
device which communicates with other network devices over a network and which can dynamically determine the 
network media type. 

Computerized local area networks (LAN's) are in widespread use for interconnecting many different computers 
and peripherals so as to allow users of the computers to communicate with one another and also to allow those users 
shared access to the peripherals. LAN's today are ordinarily organized into two different media types or architectures. 
Ethernet or token ring. Ether net is a bus architecture in which each device can transmit messages to and receive 
messages from the LAN; token ring is a circular architecture in which a token is passed sequentially to each device 
and only the device with the token can transmit a message to the LAN. Because of fundamental differences in com- 
munications and in electrical connectivity, a token ring device cannot operate on an Ethernet medium, and vice versa. 
Accordingly, a network interface device will include media-type specific hardware components for interfacing with the 
LAN. 

Recent developments in LAN's have seen the introduction of so-called "heterogeneous" LAN's, i.e., LAN's on which 
many different communication protocols are carried on a single Ethernet or token ring medium. Examples of different 
protocols are IPX/SPX, which is used by DOS-based PC's, TCP/IP, which is used by UNIX-based workstations, and 
AppleTalk, which is used by Macintosh computers. 

In order for a peripheral to be shared on a heterogeneous LAN, the peripheral must have an appropriate protocol 
stack for each of the different protocols carried on the LAN. A protocol stack is a software module that processes 
packets of data which are received from or are transmitted to the LAN using the corresponding protocol. Each protocol 
has fixed rules that govern the exchange of information between two communicating devices, and the protocol stack 
ensures compliance with those rules. In a modular software implementation, the protocol stacks for the various proto- 
cols can be implemented independent of the hardware platform media type andean share a media-type specific module 
which interfaces with the LAN. 

Complicating an already difficult situation, each of the different protocols can use any one of several different frame 
types. A frame type defines the format of a communication packet, i.e., the location and order in which information 
such as address data, protocol information, and data to be serviced by a peripheral server are presented in the packet. 
Thus, on an Ethernet medium, the protocols can use any of 802.2, 802.3, Ethernet J I, or Ethernet_SNAP frame types, 
whereas on a token ring medium, the protocols can use either a Token-Ring or Token -Ring_SNAP frame type. Thus, 
before a peripheral can provide shared access to itself from any one of different users on a heterogeneous LAN, the 
peripheral must know the protocols in use and the frame type used for each protocol. ^ * 

In addition, the protocol stacks that provide network communication functions to software applications executing 
on the peripheral sometimes need to know whether the peripheral is connected to an Ethernet or a token ring medium. 
For example, the media type must be known to perform a so-called "multicast" transmission to all devices in a specific 
group. Multicasts allow efficient transmission to a group of devices without requiring every network device to process 
a broadcast transmission. Generally, when transmitting a packet a protocol stack must provide a destination address 
to the media-type specific module that interfaces with the LAN. For broadcasts and direct transmissions, the format of 
the destination address is the same on both Ethernet and token ring media, but multicasts require a different destination 
address format on different media types. Accordingly, a protocol stack must know the media type in order to provide 
a proper destination address to perform multicast transmissions. 

There are various ways that information indicating the media-type can be provided to a protocol stack software 
module. One way is to provide a configuration file from which a protocol stack module can read data indicating the 
media type. Another way is to have different versions of the protocol stack software for different media types, and to 
link the version appropriate to the media type in use. Each of these methods requires advance knowledge of the media 
type so that a human can selectively set appropriate data in a configuration file or can selectively link the appropriate 
software version. Therefore, using these methods of determining media type, a protocol implementation that supports 
multicasts must be preconfigured for use with a particular media type and cannot be designed generically for use with 
either media type. 

A protocol stack that supports multicasts can be designed generically for use with either media type if the media 
type can be dynamically determined by the protocol stack. One method of doing this is for a protocol stack to read a 
variable set in global memory by a low-level network interface driver software module. However, this method cannot 
be used if the network interface driver and the protocol stacks are not designed to exchange data concerning the media 
type, for example, if the protocol stacks are provided by a different vendor than the network interface driver. 

Accordingly, conventional methods do not albw a media type to be dynamically determined in such a manner that 
a protocol stack which supports multicasts can be written to work generically with different network interface drivers 
and different media types. 
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These needs are addressed by the present invention, in which a network media type is dynamically determined 
in such a manner that a protocol stack can be written generically to workfor example with either an Ethernet or a token 
ring medium. 

In one aspect, the present invention is a method for dynamically determining a media type of a LAN to which a 
network device is connected. A network interface driver software module is executed which is the lowest level of soft- 
ware to communicate with the LAN and which handles the sending and receiving of communication packets to and 
from the LAN by appending or stripping off packet frame headers. The network interface driver software mod ule has 
one or more logical boards for processing communication packets having different respective frame ty pes and has one 
or more configuration tables, ea ch respectively ass ociated with one of the logical boar ds, which each include a frame 
Jtype identify in g value that identifiesa com binati°J °j ^"IgJ y P* 3 ancl meQ, ' a typg f° r packets processed by the corre- 



_ spondinSlogicaTHoaKl^ The network Interface driver afso has a semcajroutigej^ an entry : : pojnj_. 

One or more jjrotocql stack m odules are executed for processing, packets^ that use different respective protocols, and 
a multiplexer software module is executed which interfaces between the network interface driver software module and 
the one or more protocol stack modules and which routes packets from the network interface driver software module 

is to the respective protocol stack modules according to the protocol used by the packets. The entry point for the network 
interface driver service routine is obtained via the multiplexer software module, and a location of one of the configuration 
tables is obtained via the service routine. The frame type identifying value in the one configuration table is read, and 
the network media type is determined by comparing the frame type identifying value read from the one configuration 
tab|e to one or more values that correspond to a predetermined media type._ 

20 By virtue of this arrangement, a protocol stack can be loaded and executed on any network device regardless of 

media type, without needing advance knowledge of the media type in order to preconfigure the protocol stack to operate 
with a particular media type. Moreover, the media type can be determined even if the network interface driver and the 
protocol stack are provided by different vendors. 

According to another aspect, the present invention is a network interface device which interfaces with a LAN and 

25 which dynamically determines a media type of the LAN to which the network device is interfaced. The network interface 
device includes a storage device that stores (i) a network interface driver software module which is the lowest level of 
software to communicate with the LAN and which handles the sending and receiving of communication packets to and 
from the LAN by appending or stripping off packet frame headers, wherein the network interface driver software module 
has one or more logical boards for processing communication packets having different respective frame types, and 

30 wherein the network interface driver software module has a configuration table for each of the one or more logical 
boards and each configuration table includes a frame type identifying value that identifies a combination of frame type 
and media type for packets processed by the corresponding logical board, (ii) one or more protocol stack modules for 
processing packets that use different respective protocols, and (iii) a multiplexer software module which interfaces 
between the network interface driver software module and the one or more protocol stack modules and which routes 

35 packets from the network interface driver software module to the respective protocol stack modules according to the 
protocol used by the packets. The network interface device also includes a processor that (i) executes the network 
interface driver software module, the multiplexer software module, and the one or more protocol stack modules, (ii) 
reads the frame type identifying value in one of the configuration tables, and determines the network media type by 
comparing the frame type identifying value read from the one configuration table to one or more values that correspond 

^o to a predetermined media type. 

By virtue of this arrangement, a network interface device can be connected to either an Ethernet or a token ring 
medium without reconfiguring or exchanging the protocol stack software. 

Embodiments of the present invention will now be described with reference to the accompanying drawings, in 
which: 

45 

Figure 1 is an overall system view of a local area network using an Ethernet medium; 
Figure 2 is an overall system view of a local area network using a token ring medium; 

Figure 3 is a view of a cut-away section of a local area network which shows a network interface board installed 

in a multi-device controller (MDC) which includes a core board for controlling a digital copier; 
50 Figure 4 is a block diagram of the network interface Board; 

Figure 5 is a view illustrating program modules stored in persistent storage on the network interface board; 

Figure 6 is a flow diagram for explaining the general operation of the network interface board; 

Figures 7A and 7B are diagrams showing the network communication software architecture on the network during 

frame type scanning and after protocol stacks are loaded; 
55 Figure 8 is a flow diagram showing a process for autosensing of a frame type used for a protocol; 

Figures 9(a) through 9(d) are diagrams for an example in which a frame type pre-scanning program registers with 

IPX on 802.2, which shows relationships of various network software modules during autosensing of frame types; 

Figure 10 is a flow diagram showing a process for receiving a packet from a network; 
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Figure 11 shows a format of an event control block used in receiving and transmitting packets; 

Figure 12 is a flow diagram showing a process for transmitting a packet to a network; 

Figure 13 is a flow diagram showing a process for dynamically determining a network media type; 

Figures 14(a) and 14(b) are flow diagrams showing a process for reconfiguring which protocol stacks are loaded 

and/or which frame types are assigned for loaded protocol stacks; 

Figures 1 5(a) through 1 5(d) illustrate formats for different packet types used in connection with reconfiguration; and 
Figure 16 is a flow diagram showing a process for transmitting new configuration information to a network device 
from a computer via a LAN. 

-P. SystemJD^scriptiOD] 

Generally, the present invention is applicable to any device which communicates with other devices via a network. 
Preferably, the invention is used in an embedded device such as a network interface board (NIB) for connecting a 
copier to a network. The invention can also be used in a network expansion board (NEB) or a network expansion device 
(NED) for connecting a printer or other peripheral, such as a scanner, to a network. The present invention also has 
utility for computers connected to a network. 

Figure 1 is an overall system view of a network. The network includes LAN 1000, a plurality of computers, and a 
plurality of peripherals to which the computers share access. The computers shown in Figure 1 include a PC 1500 
which serves as a system administrator's computer, a PC 1530 which serves as a print server for printers 1550 and 
1540, a Macintosh-type computer 1525, a Unix-type workstation 1535, and a generalized workstation 1536 which has 
a central processing unit 1537 and a display 1538. A file server 1510 allows shared access to a network disk 1520. 
Also, NED 1600 allows shared access to a printer 1560 and NEB 1700 allows shared access to a printer 1570. As 
depicted in Figure 1 , LAN 1000 is an Ethernet medium having a bus-type architecture. 

Alternatively, as shown in Figure 2, LAN 1000 can be a token ring medium having a ring-shaped architecture. A 
token ring medium uses a different type of physical wire, different electrical connections, and different communication 
techniques than an Ethernet medium. Therefore; operation of a device on a token ring medium is mutually exclusive 
of operation on an Ethernet medium. 

Figure 3 illustrates a cut-away section of LAN 1000 which includes a network interface board (hereinafter "NIB") 
50 installed in a multi-device controller 20 which also controls a digital copier 10. LAN 1000 as depicted in Figure 3 
can be either an Ethernet or a token ring medium. 

As seen in Figure 3, a digital copier 10 includes a document feed section 11, a paper supply storage section 12, 
and a sorter/stacker 14. A suitable digital copier for use in the present invention is a Canon GP55F digital copier. As 
is known, such digital copiers operate to feed documents in document feed section 11 past a digital scanner so as to 
obtain a digital image of the scanned-in document. An unshown internal printer prints the scanned-in digital image onto 
paper supplied from paper supply storage section 12 and ejects the printed image to sorter/stacker 14. 

A multi-device controller (hereinafter "MDC") 20 accesses an interface bus (not shown) of digital copier 10 so as 
to break out the functionality of the scanner section and the printer section. MDC 20 includes a core board 24 (not 
shown) which accesses the interface bus of digital copier 10 and which provides access to that interface bus for plural 
option boards which are connectable to the core board. The option boards communicate with the core board via master/ 
slave communication through dual port RAM on each option board. Most typically, one of the option boards will include 
an interface board so as to permit connection to MDC 20 by a stand-alone computer such as computer 21. Option 
boards may also include a facsimile board so as to permit connection to a facsimile device via a telephone line 22, 
rasterizer boards so as to permit rasterization of page description language commands such as PCL5, LIPS, Postscript, 
and the like, and image processor boards which perform advanced image processing functions. 

Most notably, one of the option boards is a network interface board (NIB) 50 connectable to the core board in MDC 
20 so as to permit access to a local area network such as LAN 1000. 

In operation, digital copier 10 is operable in a stand-alone mode as a standard digital copier. In addition, it is 
operable as a scanner or as a printer to local users via personal computer 21 . Most typically, via NIB 50, and in coor- 
dination with MDC 20, digital copier 10 is operable as a multifunctional network device accessible via a LAN 1000 by 
any of multiple network users who may desire concurrent use of the scanner in copier 10, the printer in copier 10, or 
one of the option boards in MDC 20 such as the aforementioned facsimile option board, rasterizer option board, or 
image processing option board. 

[2. Network Interface Board] 

Figure 4 is a functional block diagram of NIB 50. Broadly speaking, NIB 50 is an interactive network circuit board 
which couples copier 10 to LAN 1000, making copier 10 a responsive and interactive network member. In this way, the 
printing and scanning functions of copier 10 can be utilized by users at other network devices. NIB 50 receives print 
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data, status requests, and control commands from LAN 1000, transmits print data, status requests, and control com- 
mands to copier 10 for execution, and transmits status information back to LAN 100. Thus, NIB 50 can perform not 
only LAN "print services", e.g., RPRINTER remote printer services and PSERVER print server functionalities, but can 
also offer to network members whatever status and control features are available from the peripheral interface. 
5 Power for all circuits is supplied to NIB 50 from a +5V power source 398. Power is provided from power source 

398 to power converter 396 which provides -9V power to a transceiver 390 and to power converter 397 which provides 
+1 2V power to a flash EPROM 350 for "flashing" (i.e., reprogramming of the EPROM). Network and network interface 
control logic 340 is preferably a single 144-pin application specific integrated circuit (ASIC) that includes a network 
controller 330 and interface control logic 320. Network controller 330 is an NCR macro-cell compatible with a National 
-10 DRB3Q02A "ST-NJCLEtharnet controller, the details of which can be found in National Semiconductors Local Area 



Networks Databook , National Semiconductor p/n 400055, National Semiconductor, 1993. Network controller 330 is 
designed to interface with CSMA/CD-type (carrier sense multiple access with collision detection) local area networks. 

Network controller 330 connects with RJ-45 connector 385 directly and with coaxial connector 395 through trans- 
ceiver 390, which is preferably a National Semiconductor DP8392C coaxial transceiver interface, the details of which 

is can also be found in National's Local Area Networks Databook . Network controller 330 also connects with AUI (At- 
tachment Unit Interface) connector 386. AUI connector 386 is the most shielded, i.e., has the greatest noise immunity, 
of the three connectors. Network controller 330 is also coupled to an 8KB SRAM 380 that is used as an input/output 
packet buffer for Ethernet data. This memory should preferably have an access time of about 70 ns or less. 

Interface control logic 320 provides an interface between network controller 330, microprocessor 300, and memory 

20 devices EPROM 350 and DRAM 360. Interface control logic 320 also interfaces with non-volatile random access mem- 
ory (NVRAM) 370, which preferrably is a 1 KB (1024 byte) serial electrically erasable/programmable memory used for 
initialization data storage during power cycling of copter 10. Network and peripheral configuration parameters are 
written into NVRAM 370 when copier 1 0 is first installed onto the network to allow NIB software to recover the installation 
parameters after MDC power has been cycled off and on. 

25 Interface control logic 320 also couples with serial port connector 325, which comprises a receive data pin 326 

and a transmit data pin 327 that can respectively receive and transmit serial data streams for debugging purposes. 
Interface control logic 320 senses data present at the receive data line and samples the serial bits at regular intervals. 

The central controller of NIB 50 is microprocessor 300, which is preferably an NEC uPD70236 (V53) 16-bit proc- 
essor, the details of which can be found in the NEC V53 User's Manual, NEC, Inc. This processor is an 16-bit processor 

30 with direct memory access (DMA), interrupts, timers, and a DRAM refresh control. Other microprocessors, such as an 
AMD 80C188-20 16-bit microprocessor, might alternatively be used. 256 KB flash EPROM 350 and 512 KB DRAM 
360 are coupled to microprocessor 300 via interface control logic 320. A 40 MHz, 50 ppm crystal oscillator 310 provides 
microprocessor 300 with a clock signal that is wholly separate from and asynchronous with the clock signal of MDC 
20 or that of copier 10. All communication between NIB 50 and MDC 20 occurs over a special bus 405 via an 8 KB 
b . 35 dual port RAM (DPRAM) 400. Special bus 405 has a 96 pin connector and carries sixteen data bits, sixteen address 
bits, a chip select signal, memory read and write signals, buffer enable and read signals, a clock input signal, and the like. 

Microprocessor 300 executes instructions stored in flash EPROM 350, which stores control firmware and printing 
application software. After power-on self-test (POST), code from EPROM 350 is selectively moved to the higher per- 
formance 512 KB DRAM 360, which should preferably have an access time of about 80 ns, for actual execution. 

^o All software modules executed by microprocessor 300 are stored in flash EPROM 350. Those modules that are 

needed are selectively loaded from EPROM 350 into DRAM 360 and are executed from DRAM. This permits flexible 
configuration of NIB 50 by selection of which modules are to be loaded. Alternatively, software modules can be down- 
loaded via the LAN or a serial port. 

A configuration file 75 is stored in, for example, NVRAM 370 which is processed by microprocessor 300 upon 

45 power on or receipt of a boot-up command. The configuration file ordinarily directs processor 300 as to how to partition 
memory, what memory-resident programs are to be loaded from EPROM 350 into which areas of memory, what ap- 
plication programs-are to be started as concurrently executed tasks, and the like. For example, configuration file 75 
may include instructions to microprocessor 300 to dedicate certain areas of DRAM 360 for network communication 
protocol. Further, the modules to be loaded may be indicated by using a bit mask which has a bit corresponding to 

50 each module stored in EPROM 350. A "loader" module stored in EPROM 350 which executes after the above-men- 
tioned POST routine checks the state of each bit in the mask and, if the bit is "1 loads the corresponding module from 
EPROM 350. 

Figure 5 illustrates an example of software modules (or programs), that are stored in flash EPROM 350. XPSERV- 
ER is a module that provides a standardized interface between NIB 50 and MDC 20. MLID (Multi-Link Interface Driver) 
55 166 serves as a network interface driver, while LSL (Link Support Layer) 187 serves as a multiplexer software module 
which multiplexes between MLID and the protocol stack modules. An IPX protocol stack module 1701 for supporting 
IPX/SPX protocol used by NetWare (Novell's network software) is also contained in EPROM 350. Since NIB 50 can 
support multiple protocols, it can include protocol stacks for other modules, such as a TCP/IP protocol stack module 
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1702 and an AppleTalk protocol stack module 1703, for example. Other protocols such as NetBIOS/NETBEUl also 
may be supported. 

In the preferred form of the invention, the network interface driver, multiplexer, and protocol stack modules conform 
to the Open Data-Link interface (ODI) specification described in 'Open Data-Link Interface Developer's Guide for DOS 

s Workstation Protocol Stacks", Version 1.10, Released by Novell, Inc., March 18, 1992. Particularly, MLID 1B6 is the 
lowest level of network connection software and handles-sending and receiving of packets to and from the network by 
adding or stripping off frame headers. MLID 186 includes a separate board for processing each frame type that may 
be used on the network. The boards may be logical boards or physical boards, but logical boards are used in the 
preferred embodiment. In an Ethernet device, there are four logical boards, with logical boards 0 through 3 respectively 

io processing frame types 802.3, 802.2, Ethernet,!!, and Ethernet_SNAP. A token ring device has only two lo gical boards 
for respectively processing Token-Ring and Token-Ring_SNAP frame types. 

For each logical board, MLID 186 has a configuration table that stores configuration information for the logical 
board, such as the information indicated in the MLID configuration table format of the above-referenced ODI specifi- 
cation. For example, this information includes the configuration table version, node address, board number, maximum 

is packet size, best data size, worst data size, frame type ID, transport time, source route handler, line speed, queue 
depth, number of send retries, default base memory address, memory size, etc. 

The frame type ID is a value identifying the frame type processed by the logical board corresponding to the con- 
figuration table. In an Ethernet device, the frame type ID values shown in Table 1 are used, and in a token ring device, 
the frame type ID values shown in Table 2 are used: 

20 



Table 1 


Frame Type 


ID Value 


EthemetJI 


2 


802.2 


3 


802.3 


5 


Ethemet_SNAP 


10 



30 Table 2 



Frame Type 


ID Value 


Token -Ring 
Token-Ring_SNAP 


4 
11 



LSL 187 (link support layer) comprises software code that acts as a multiplexer between the lowest level MLID 
186 functionality and network protocol stacks above. Since several different protocols can be used on LAN 1000, and 
some may even use the same frame type, some provision is needed to route packets from MLID 186 to the correct 
protocol stack. LSL 187 performs that function. In particular, LSL 187 assigns a Protocol ID (PID) to each loaded 
protocol stack. The PID is included in a packet and is used by LSL 187 in conjunction with the frame type to route a 
received packet to a protocol stack. In particular, LSL 187 accepts registrations of any of the various frame types with 
which frame packets may be carried on the network. Thus, for example, in an Ethernet environment, LSL 187 will 
accept registrations of 802.2, 802.3, EthemetJI, and Ethernet_SNAR and in a token ring environment LSL 187 will 
accept registrations for Token-Ring and Token -Ring_S NAP. By registering a frame type with LSL 187, a software module 
above LSL 187 instructs LSL 187 to provide the module with all frame packets that match the registered frame type. 
Other multiplexer software modules that perform the same function may be used. 

The protocol stacks 1701-1703 perform the function of receiving packets for the respective protocols, determining 
what needs to be done with the packets, and sending the packets to the necessary destination, e.g., a print server 
module or a scan server module. 

CNETX is customized code that turns local DOS-like function calls into network function calls, providing file func- 
tions like OPEN, READ, WRITE, and CLOSE. CNETX also provides NCP (NetWare Core Protocol) for NetWare server 
modules. The pre-scanning program B4 is responsible for identifying what frame types are associated with the various 
possible protocol stacks. Because NIB 50 supports multiple protocol stacks, this module exists as long as NIB 50 is 
running. 

Pre-scanning program 84 performs a so-called "autosensing" (AS) function to identify what frame types (such as 
802.2, 802.3, EthemetJI or Ethernet_SNAP for an Ethernet medium) are associated with what protocol stack (for 
example, IPX/SPX or TCP/IP). The operation of pre-scanning program 84 is described in detail below. Pre-scanning 



6 



EP 0 767 565 A2 



program 84 includes a portion which performs a so-called ■configurator* function, which is also described in detail 
below. The configurator function allows reconfiguration of loaded protocol stacks and frame type assignments from a 
remote computer. 

EPROM 350 also includes software to export the functionality of copier 10 onto the LAN. CPSERVER (PSE) 79 
s is a custom implementation (or emulation) of a Novell NetWare printer server application. This module provides self- 
generated print banners, user notification of completion and exception status, and transmission of print data and status 
commands to copier 10 when serving as a printer. This differs from the Novell print server in that CPSERVER is ded- 
icated to driving the local printer (i.e., copier 10 to which NIB 50 is coupled) and cannot drive any remote RPRINTERs. 
This program owns the print data lines for the duration of a print job. CRPRINTER is a custom implementation of a 
10 Novell RPRINTER print application. This module is a stave application that is sent data by a Novell printer server 
application elsewhere on LAN 10. EPROM~350 also includes an LPD~(Ltne pnnter Daemon) module, which is a print" 
application for UNIX, and an APS (Apple Print Server) module, which is a print application for Macintosh. 

EPROM 350 can also include other servers, such as an FSC task which handles fax status and control tasks, an 
FSR task which handles fax send and receive tasks for a facsimile board present in MDC 20, a scan server, and an 
is image processing server. Those other servers operate to export functionality of other option boards connected to MDC 
20. 

The CPSOCKET program runs for all protocol stacks. The program responds to requests for remote utilities con- 
nection, requests for data download, or requests for services from remote utilities, and provides status and control to 
other tasks via interprocess communication. Because CPSOCKET typically owns the status and control lines between 
20 NIB 50 and MDC 20, it is the only task that has the ability to obtain status data from copier 10 via the status lines. 
CPSOCKET is responsible for the network connection and packet contents between, for example, the Novell-oriented 
status and control utilities, between the UNIX-oriented status and control utilities, or between Macintosh-oriented status 
and control utilities. 

MONITOR is a customized multi-tasking kernel which performs task creation, task destruction and microprocessor 
25 dispatch. MONITOR also has memory management sub-modules MEMGET and MEMFREE. RESIDENT is a block 
of routines that provides generic services such as read and write to flash EPROM 350, FLASH code, ROM based 
debugger, hardware timer tick and other basic features. POST is the power-on self -test module that checks the integrity 
of NIB hardware and software at power-up. 

A network identification file (NIF) data block is also provided which stores board-invariant information, which is 
30 unique for every network board (e.g., a MAC (media access control) address), hardware configuration data, board 
revision number and the like, as well as changeable information such as software version number. On the NIB, the 
NIF is stored in a separate ROM. On other interface boards, such as NEBs and NEDs, the NIF may be stored in EPROM 
350. The information in the NIF data block is used, among other things, to ensure that flash EPROM 350 is not repro- 
grammed with an incompatible firmware image. 
-35 Specifically, EPROM 350 stores "board" information such as model number, firmware level, and board revision 

number, as well as "network" information such as Media Access Control (MAC) address, which is unique for every 
network board, board name, primary file server identification, queues serviced, sampling frequency PSERVER name, 
zone-name, and the like. 

^0 [3. Operation] 

Operation of the network interface board will now be explained with reference to the flow diagram shown in Figure 
6. The process steps shown in Figure 6 are executed by microprocessor 300 by loading the software modules shown 
in Figure 5 into DRAM 360 and executing the process steps from DRAM. 

45 In step S601 , upon application of power or suitable logic reset, CPU 52 initiates boot -up processing by reference 

to configuration file 75. The configuration file, as mentioned above, can include various options fixing the configuration 
of NIB 50, such as memory allocation, operating system, etc. Ordinarily, configuration file 75 configures NIB 50 as a 
network interface board interfacing between the network and MDC 20. In that instance, configuration file 75, as men- 
tioned above, includes configuration of memory, allocation of memory space for various memory-resident programs 

50 such as a network communication stack, and initiation and loading of various program modules. 

As shown in Figure 6, in step S602, microprocessor 300 loads its network communication software. Specifically, 
microprocessor 300 loads ML1D 1S6 and LSL 187 into memory allocated for them (typically high memory), and in 
addition loads whatever network communication stacks are needed for participating in network communications in the 
network environment that NIB 50 is installed in, as indicated by default configuration information in configuration file 

55 75. For example, in a situation where a Novell NetWare network environment has been established, microprocessor 
300 would load an IPX/SPX network communication stack into memory. Likewise, in a situation where a UNIX network 
operating system is in place, microprocessor 300 would load a TCP/IP network communication stack into memory. 
Whether to load IPX/SPX, TCP/IP, AppleTalk, or any combination, is stored as part of the default start-up script in 
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configuration file 75. 

As mentioned above, pre-scanning program B4 can detect what frame type is being used on the network for each 
protocol. However, default data in configuration file 75 can alternatively be used to assign a frame type to each loaded 
protocol stack. In the preferred form of the invention, configuration file 75 contains data for a default configuration in 
5 which a TCP/IP protocol stack is loaded and assigned an Ethernet J I frame type, an AppleTalk protocol stack is loaded 
and assigned a Phase 2 (Ethernet_SNAP) frame type, and an IPX/SPX protocol stack is loaded and assigned a frame 
type by autosensing using pre-scanning program 84. 

In step S603the needed network servers,(such as CPSERVER 79 and the like) are all loaded. Then, in step S604, 
NIB 50 waits for a request for network services. Until a request for network services is received, NIB 50 stands by in 
io an idle state, responding to access inquiry commands from core board 24 with simple acknowledgement ("ACK"). On 
the other hand, as soon as a request for network services is received, either from the network or from a local user such 
as a user operating digital copier 10, flow advances to step S605. 

In steps S605 and S606, after a request for network services has been received, the request is serviced. In par- 
ticular, in step S605, microprocessor 300 initiates execution of the appropriate network server. For example, in a situ- 
15 ation where a request for print services is requested, microprocessor 300 initiates execution of CPSERVER 79. 

In step S606, microprocessor 300 continues execution of the needed server so as to service the request. Then, 
flow returns to step S604 to wait for additional requests for network services. Meanwhile, services already being proc- 
essed in step S606 continue until they are complete. Should additional requests be received, then microprocessor 300 
initiates execution of the appropriate server (step S605) and begins servicing the request (step S606). Concurrent 
20 network processing, to the extent physically supported by devices controlled by NIB 50, is then carried out. 

[3.1 Autosensing Frame Types and Configurator Function] 

As mentioned above, the system includes a configurator function that allows the protocol stacks which are loaded 

25 jn a peripheral and the frame type assignments for each loaded protocol stack to be reconfigured from a computer at 
a remote location. In the preferred embodiment, the configurator function is encoded as part of pre-scanning program 
84 and relies in part upon the operational relationship between pre-scanning program 84 and LSL 187 to receive 
packets from the remote computer which contain new configuration information. 

Figure 7A shows the software architecture in NIB 50 during initialization, while pre-scanning program 84 is deter- 

30 mining frame types and before any of protocol stacks 1701 -1703 are loaded. In that situation, MLID 186 interfaces with 
LAN 1000, LSL 187 is on top of MLID 186, and pre-scanning program 84 is on top of LSL 187. Figure 7B shows the 
software architecture after protocol stacks have been loaded. In this case, protocol stacks 1701-1703 are loaded on 
top of LSL 187, but pre-scanning program 84 remains resident for reasons described below and is also on top of LSL 
187. CPSOCKET is loaded on top of all protocol stacks to receive network requests for services or status. Print (or 

35 other service) application modules also load on top of the protocol stacks. 

As mentioned above, pre-scanning program 84 performs a function of monitoring network broadcast traffic in de- 
tecting what frame type is used for a particular protocol or protocols, and assigning the detected frame type to the 
associated protocol. As such, pre-scanning program 84 receives all packets that are not wanted by any protocols that 
have registered with LSL 187 for each frame type. The reception of packets in this manner is important to the auto- 

40 sensing function, which is described next, and is also important to the configurator function described below. It should 
be noted that autosensing of frame type/protocol assignment is a configurable option, because the frame type/protocol 
assignments can be pre-assigned, for example, using a configuration file. The configurator function, on the other hand, 
is always active. 

Figure 8 and 9(a) through 9(d) illustrate one implementation for performing autosensing. Figure 8 is a flow diagram 
45 showing process steps which are executed by NIB microprocessor 300 in accordance with an exemplary embodiment 
of pre-scanning program 84 loaded from EPROM 350. Specifically, the process steps of Figure 8 illustrate a method 
for loading a network communication stack in accordance with step S602 of Figure 6. 

Figures 9(a) through 9(d) show the functional relationships between different software modules during autosensing. 
In particular, those figures show an example of autosensing in which pre-scanning program 84 assigns frame type 
50 802.2 to IPX. The actual structure that implements the process of Figures 8 and creates the functional relationships 
can be understood with reference to Figure 4. Software modules stored EPROM 350 are loaded into DRAM 360 under 
the control of microprocessor 300. The needed software modules are then executed by the microprocessor 300. As- 
suming an Ethernet medium, packets are received over a physical wire at RJ45 connector 385 and are routed to 
network controller 330. Packets that are intended for NIB 50 are then stored in DRAM 360 under the control of micro- 
ns processor 300, and packets are routed between software modules by passing the memory address where the packet 
is stored. 

Referring now to Figure 8, in step S801, microprocessor 300 loads LSL 187 (link support layer) and begins exe- 
cuting LSL 1 87. As discussed above, LSL 1 87 acts as a multiplexer between the low level MLID 1 86 (multi-link interface 
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driver) and various protocol stacks which may be loaded above it. 

In step S802, microprocessor 300 loads MLID 186. As described above, MLID 186 is the lowest level of software 
that communicates to the network. MLID 186 thus acts as the direct software interface to the network frame packets 
which are carried on the network wire. Other network interface drivers that perform the same function may be used. 

In step S803, microprocessor 300 loads pre-scanning program 84 on top of LSL 187. As mentioned above, pre- 
scanning program 84 is responsible for identifying, if so configured, what frame types are associated with the various 
protocols in which NIB 50 is adapted to communicate. In step S804, pre-scanning program 84 registers to receive from 
LSL 187 all frame types that are supported by MLID 186, thereby instructing LSL 187 to provide pre-scanning program 
84 with all frame packets which match any of the registered frame types and are not wanted by any protocol stacks 
also registered for the frame type. 
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Flow then advances to step S805 in which MLID 186 and LSL 187 monitor the network for any traffic. SpeafTcaliyT 
in step S805, the network is monitored for packets addressed to the NIB's MAC address and for broadcast traffic, 
meaning that the destination of the traffic is unspecified (i.e., "to anyone"). Ordinarily, broadcast traffic is identified by 
a global specification for the destination media access control (MAC) address, for example 12 hexadecimal F's in 
sequence. Until LAN broadcast traffic is detected, pre-scarining program 84 does nothing. 

At this point in pre-scanning program 84's execution, the relationship of the various software modules is as depicted 
in Figure 9(a). As seen -there, it is possible for multiple network devices, such as devices 182, 183, 184, and 185, each 
of which runs a different protocol, all to be connected to a single LAN 1000. The devices may use the same or different 
frame types. In Figure 9(a), device 182 is a Novell device running an IPX/SPX protocol using an B02.2 frame type; 
device 183 is a UNIX network device running a TCP/IP protocol using an EthernetJI frame type; device 184 is a 
Macintosh device running an Ethernet protocol using an Ethernet_SNAP frame type; and network device 185 is an 
unidentified frame and protocol device using an 802.3 frame type. Of course, the combinations shown in Figure 9(a) 
are illustrative only. 

NIB 50 is also connected to LAN 1000 and includes LSL 187 loaded on top of MLID 186. Pre-scanning program 
84 is shown as having registered each of the different frame types which may be exchanged on LAN 1000. Thus, as 
shown in Figure 9(a), which depicts an Ethernet environment, pre-scanning program 84 has registered 802.2 at 189, 
EthernetJI at 190, Ethernet_SNAP at 191, and 802.3 at 192. 

When LAN broadcast orNIB-directed traffic is detected, flow advances to step S806 of Figure 8 in which LSL 187 
provides the frame packet to pre-scanning program 84. In step S807, pre-scanning program 84 decodes the frame's 
protocol header so as to identify the protocol in use by that frame packet. This header varies depending on the frame 
type the protocol is-using. 

Figure 9(b) illustrates this sequence. As seen in Figure 9(b), network device 182 has issued a broadcast frame 
packet using an B02.2 frame type. Since pre-scanning program 84 has registered 802.2 with LSL 1 87, at 1 89 as shown 
in Figure 9(a), LSL 187 provides the frame packet to pre-scanning program 84. Pre-scanning program 84 decodes the 
frame's protocol header using the above table so as to determine the protocol in use on that frame type. 

Examples of allowable frame types for IPX/SPX, TCP/IP, and AppleTalk are as shown in the following Table 3: 

Table 3 



IPX/SPX 


TCP/IP 


AppleTalk 


EthernetJI 
Ethernet„SNAP 

802.2 

802.3 


EthernetJI 
Ethernet_SNAP 


EthernetJI (Phase 1) 
Ethernet_SNAP (Phase 2) 



55 



As is evident from the above list, it is possible for two of the frame types (EthernetJI and Ethernet_SNAP) to be 
used by different protocols. It should also be noted that it is permissible for the same frame type to be used by different 
protocols on the same LAN. Since pre-scanning program 84 remains registered with LSL 187 for all frame types, 
detection is possible even for frame types for a protocol different from those already registered by pre-scanning program 
84 and is required in connection with a configurator function described below. By this arrangement, NIB 50 can be 
reconfigured by a device communicating on the network using a protocol for which no protocol stack is loaded in NIB 
50 or a protocol/frame type combination which NIB 50 is not pre-configured to receive. 

In step S808, pre-scanning program 84 determines whether autosensing is complete, i.e., whether all protocols 
for which autosensing is to be performed have been assigned a frame type. If not, flow returns to step S805 to monitor 
LAN broadcast traffic. On the other hand, if all protocols requiring autosensing have been assigned a frame type, flow 
proceeds to step S809. In step S809, pre-scanning program 84 terminates its pre-scan operation but remains resident 
in DRAM 360 to perform the configurator operation discussed below. Pre-scanning program 84 also issues a command 
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to cause the required protocol stacks to be loaded. The configurator function described below is performed before, 
during, and after any autosensing. 

In step S810, the newly-loaded protocol stacks register with LSL 187, as shown, for example, in Figure 9(c). As 
seen there, the IPX/SPX protocol stack registers 802.2 with LSL 187. By registering, and as described above, IPX/ 
SPX informs LSL 1 87 to provide all frame packets matching the registered frame type (here, 802.2) to the newly-loaded 
protocol stack. Further, the configurator always stays registered to all frame types. Thus, in the example for 802.2 
frame packets, any packet the IPX protocol stack doesn't want will be passed on to the pre-scanning program 84/con- 
figurator module. 

When a protocol stack is loaded, a software interrupt is performed to obtain a table of entry points into various 
service routines provided by LSL 1 87. Thereafter, when the protocol stack wishes to u tilize an LSL service routine, it 
merely performs a call to the memory address serving as the entry point to the desired routined 

As shown in Figure 9(d), once a protocol stack has been loaded, it begins to operate on the network. Specifically 
whereas pre-scanning program 84 was completely passive and did not broadcast any network communications, pro- 
tocol stacks broadcast their associated requests. For example, IPX/SPX broadcasts its associated SAP requests, and 
TCP/IP broadcasts its associated RARP's so as to obtain its address from the nearest network server. 

[3.2 Processing Of Received Packets] 

Figure 10 is a flow diagram showing a process for receiving a packet from LAN 1000. In step S1001. a packet is 
received by a network interface chip, such as network controller 330 in an Ethernet environment, network controller 
330 determines in step S1002 whether the packet is addressed to NIB 50. Every packet transmitted on LAN 1000 has 
a header including network destination information. For example, the network destination may be the MAC address of 
a specific device, i.e., a direct transmission, or the destination may be all devices, i.e., a broadcast to hexadecimal 
address FFFFFFFFFFFF H , for example. Generally, the destination address information is processed at the hardware 
level, e.g., by network controller 330. to determine if the packet is intended for reception by NIB 50. Accordingly, packets 
that are not intended for NIB 50 are never passed to the software executed on processor 300. Rather, only packets 
intended for NIB 50, such as broadcast or multicast or specifically-addressed packets, are passed on for further software 
processing. 

If the packet is not addressed to NIB 50. either specifically or as part of a group (e.g., broadcast or multicast), flow 
returns to step S1001 and the packet is discarded. If the packet is addressed to NIB 50, the packet is passed to MLID 
186 in step Si 003. As described above, MLID 186 is the lowest level software that communicates with the network. 

In step S1004, after MLID 186 receives a packet from network controller 330, each of the logical boards determines 
if the packet frame type is the type processed by that board. The board that processes the matching frame type strips 
off the frame header and passes the packet to LSL 187. Flow proceeds then to step S1005. In step S1005, LSL 187 
uses the board number of the logical board which forwards the packet and the Protocol ID (PID) to route the packet 
to the appropriate protocol stack, and flow advances to step S1006. In step S1006, the protocol stack processes the 
packet and routes the packet to a peripheral server, such as CPSERVER 79, for servicing. Flow then returns to step 
S1001 . Of course, different packets can be at different stages of the process in Figure 10 at the same time. 

Referring to Figure 11 . when a protocol stack wishes to transmit a packet on LAN 1000, it does so using an Event 
Control Block (ECB) 1750. As shown in Figure 11 , ECB 1750 includes the following information fields, as described in 
the above-mentioned ODI specification: EventServiceRoutine, StacktD, BoardNumber, ProtocollD, ImtnediateAddress, 
DataLength, FragmentCount, and FragmentDescriptors. 

BoardNumber is the number of the logical board in MLID 186 that handles the frame type used by the protocol 
stack. The logical board to which a protocol stack is bound, i.e., to which it sends data packets and from which it 
receives data packets, can be set in a configuration file, e.g., NET.CFG. In the preferred embodiment, since the order 
of logical boards is known, the board number to which each protocol stack should be bound is also known and is hard 
coded into the protocol stack software modules. Alternatively, the protocol stack can determine the board number of 
the board to which it should be bound, i.e., the board which handles the frame type used by the protocol stack, by 
examining the frame type ID values in the configuration table for each board. 

Using the service routines provided by LSL 187, the protocol stack can obtain an entry point to a service routine 
of MLID 186, which is then used to obtain the locations of the configuration tables. The protocol stack then can examine 
the frame type ID values from the configuration tables to determine which board handles the frame type used by the 
protocol stack. The number of that board is then used in ECB 1750. Since LSL 187 and MLID 186 do not alter ECB 
1750, the board number does not have to be redetermined each time a packet is sent, but instead can be set in ECB 
1750 once during initialization. 

The ImmediateAddress field of ECB 1750 contains the destination address that specifies to which node on LAN 
1000 the packet should be sent. This can be a direct, multicast, or broadcast address. A multicast involves sending a 
packet to each member of a group, instead of sending the packet to every device on the network using a broadcast. 
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The format of Ethernet multicast addresses differs from that of token ring multicast addresses. Thus, in contrast to 
direct transmissions or broadcasts, mufticasts require that the protocol stack be aware of the network media type, in 
order to provide the appropriate multicast address format to MLID 186. The protocol stack can, for example, obtain 
the network media type, or a specific address format for multicast use, from a configuration file, e.g., NET.CFG, as in 

s a conventional approach. The present invention provides an alternative method, as discussed below. 

Figure 1 2 is a flow diagram illustrating a process for transmitting a packet on LAN 1 000. In step S 1 201 , the protocol 
stack determines what board number should send the packet, if necessary because the board number is not hard 
coded, in the manner discussed above. In step SI 202, the protocol stack determines whether the transmission is a 
multicast. If it is not a multicast, the process skips ahead to step SI 204. If the transmission is for a multicast, flow 

10 advances to step SI 203. In step SI 203, the appropriate address format for the multicast is determined. This may 
involve retrieving a multicast address format from a configuration ffte~ordetermining the media typerSin ce t he media " 
type will not change, it need only be determined once. Appropriate data can then be stored so that the protocol stack 
knows the media type the next time a multicast is transmitted. Flow then advances to step S1204. 

In step S1204, the protocol stack forms an ECB 1750 having the information mentioned above. Flow then advances 

is to step S1205, in which the protocol stack calls LSL 187 with a pointer to the memory location of the ECB. Flow then 
advances to step S1206, in which LSL 187 calls the board of MLID 186 designated by the ECB. Flow then advances 
to step S1207, in which the MLID board transmits-the packet on LAN 1000. Flow then advances to step S1208 to 
continue with other processing. 

so [3.3 Dynamic Detection Of Media Type] 

The present invention provides a method for dynamically detecting the network media type so that a protocol stack 
can be written generically to execute in for example either an Ethernet or a token ring environment. 

Figure 1 3 is a flow diagram illustrating a process for dynamically determining a media type of a local area network 

25 (LAN) to which a network device is connected. Briefly, a network interface driver software module is executed which 
is the lowest level of software to communicate with the LAN and which handles the sending and receiving of commu- 
nication packets to and from the LAN by appending or stripping off packet frame headers. The network interface driver 
software module has one or more logical boards for processing communication packets having different respective 
frame types and has one or more configuration tables, each respectively associated with one of the logical boards, 

30 which each include a frame type identifying value that identifies a combination of frame type and media type for packets 
processed by the corresponding logical board. The network interface driver software module also has a service routine 
which can be accessed via an entry point. One or more protocol stack modules are executed for processing packets 
that use different respective protocols, and a multiplexer software module is executed which interfaces between the 
network interface driver software module and the one or more protocol stack modules and which routes packets from 

35 the network interface driver software module to the respective protocol stack modules according to the protocol used 
by the packets. The entry point of the network interface driver service routine is obtained via the multiplexer module. 
A location of one of the configuration tables is then obtained via the service routine. The frame type identifying value 
in the one configuration table is then read, and the network media type is determined by comparing the frame type 
identifying value read from the one configuration table to one or more values that correspond to a predetermined media 

^0 type. 

More specifically, in steps S1301, S1302, and S1303, microprocessor 300 loads and executes LSL 187, MLID 
186, and one or more protocol stack modules as shown in steps S801, S802, S809, and S810 of Figure 8. Process 
steps S1 304 through SI 307 then can be performed to determine the media type dynamically at any point after a protocol 
stack has obtained the entry points into service routines of LSL 187, either as part of the initial loading and execution 

is of the protocol stack or at a later time. 

In step S1304, the frame type ID value is read from the configuration table corresponding to logical board 0 in 
MLID 186, then flow advances to step S1 305. The frame type ID value is read by calling a service routine of LSL 187 
which provides the entry point for a service routine of MLID 186. The service routine of MLID 186 is then called to 
obtain the location, i.e., starting memory address, of the configuration table. The frame type ID value is then read 

50 directly from the conftguration table. 

In step S1 305, the frame type ID value is compared to the value 5. As shown above in Tables 1 and 2, the standard 
frame type ID values are assigned in such a way that the value is unique for each different frame type and media type. 
In the preferred embodiment, when an Ethernet medium is used, the four logical boards are arranged so that logical 
board 0 is the 802.3 frame type board. As shown in Table 1 , the frame type ID value for that board is 5. On the other 

55 hand, if a token ring medium is used, the first logical board is for a Token-Ring frame type and has a frame type ID 
value of 4. 

Thus, if the frame type ID value read from logical board 0 is determined to be equal to the value 5 in step S1305, 
flow advances to step S1 306 which makes a determination that the media type is Ethernet. That information may be 
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stored in configuration file 75 or in DRAM 360. Flow then advances to step S1 308 and microprocessor 300 continues 
with other processing. 

If the frame type ID value is not equal to the value 5 in step S1305, flow advances to step S1307 which makes a 
determination that the media type is token ring. Flow then advances to step S1 308 to continue with other processing. 
s There are, of course, many variations on the above process. For example, the frame type ID value for a different 

logical board can be read and compared to a value other than 5. Also, if the frame type ID value is not equal to 5 in 
step S1 305, it can be expressly compared to the value 4 to verify that logical board 0 is for a token ring medium. If the 
frame type ID value for logical board 0 does not equal either 4 or 5, the protocol stack can recognize that a problem 
exists, e.g., the logical boards are incorrectly configured or a proprietary network that is neither Ethernet nor token ring 

io is being used. 

Further, the frame type ID value for a logical board can be compared to the entire set of values that a Doard may 
have for a given media type. For example, Table 1 indicates that the frame type ID value for boards on an Ethernet 
medium will be either 2, 3, 5, or 10. If a frame type ID value read trom a board is not in that set, a token ring medium 
can be assumed. Likewise, the frame type ID value for boards on a token ring network will be either 4 or 11 . Thus, if 
is the frame type ID value is not in that set, an Ethernet medium can be assumed. 

In this way, a protocol stack can determine the media type dynamically without having any knowledge beforehand 
concerning the arrangement of logical boards, and without any special interaction with the network interface driver 
module. All that is necessary is a multiplexer module and network interface driver module which conform to the ODI 
specification, or which at least have an ODI -conforming configuration table and a way to access the information in it. 
so Accordingly, the protocol stack can be written generically, including code to perform steps SI 304 through SI 308, and 
can be loaded into any network device meeting the above conditions regardless of media type. 

[3.4 Reconfiguring Frame Type Assignments/Protocols] 

25 As mentioned above, a portion of pre-scanning program 84 provides a so-called configurator function which allows 

changes to be made to configuration information regarding which protocol stacks are loaded and which frame type is 
assigned to each loaded protocol stack. 

Figures 14(a) and 14(b) show a flow diagram which illustrates a process for reconfiguring frame type assignments 
for protocol stack modules in a network interface device which is interfaced to a local area network (LAN). Briefly an 

30 initialization process is executed which loads protocol stack modules and assigns frame types to each of the loaded 
protocol stack modules based on configuration information regarding the protocols and frame types used on the LAN. 
Packets are received which include data and address information from the LAN, and a determination is made whether 
a received packet is a configuration packet by detecting whether the packet is addressed to the NIB by using a pre- 
determined address, e.g., the packet is addressed to the NIB's specific assigned address and has the correct validation 

35 stamp. In response to a determination that the received packet is a configuration packet, the configuration information 
is altered using the data in the configuration packet. The initialization process is subsequently reexecuted using the 
altered configuration information. 

In more detail, in step S1401 a packet is received by LSL 187. The packet has been routed to this point based on 
header information including destination address information, which is identical in a configuration packet to the header 

40 information in a packet containing data to be serviced. Thus, LSL 187 cannot distinguish a configuration packet from 
other packets and determines the protocol stack to which the packet should be routed in the same manner as for other 
packets. In step S1402, a determination is made whether the appropriate protocol stack is loaded. If the protocol stack 
is loaded, flow advances to step S1403 in which the packet is routed to the appropriate protocol stack, then flow 
advances to step S1404. If the protocol stack is not loaded, flow advances to step S1 408 in which the packet is routed 

45 to pre-scanning program 84. In addition, as described below, the packet is also routed to pre-scanning program 84 if 
the protocol stack declines the packet. 

In the preferred form presently described, a packet for a loaded protocol stack is first routed to the protocol stack 
even when the packet is a configuration packet. However, since the protocol stack does not know anything about the 
configuration packet, it declines it. Handling of the configuration packet then passes to pre-scanning program 84. It is 

so possible to modify LSL 187 to distinguish configuration packets and avoid routing them to a protocol stack. However, 
since relatively few packets are likely to be configuration packets, it is preferable not to modify LSL 187 but instead to 
have a protocol stack determine whether a packet is a configuration packet. In this way, if a protocol stack is registered 
to receive the frame type used by a packet, the protocol stack gets the first chance to accept and process the packet, 
and most of the time that is what happens. Only if the protocol stack declines the packet is it passed to the configurator. 

55 Accordingly, in step S1404 a determination is made whether a packet is a configuration packet by determining 

whether the protocol stack will accept or decline the packet. A decision to accept or decline the packet is made based 
on detection of whether address data in the packet indicates the NIB's assigned MAC address and whether it includes 
an identifying ■stamp". Figure 15(a) shows a format of a configuration packet 1800 in the preferred embodiment. 1801 
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designates frame header information including the destination address information used to route the packet over LAN 
1000 to the appropriate node, NIB 50 in this case. 1B02 designates protocol header information which includes the 
information used by LSL 1 87 to route the packet to an appropriate protocol stack. 1803 designates data which will be 
discussed below. 

s The protocol information 1802 differs in form for different protocols. For example, an IPX/SPX packet will include 

address data that designates a socket, a TCP/IP packet will include address data that designates a port, and an Ap- 
pleTalk packet will include address data that designates a DDP type. A predetermined socket, port, and DDP type are 
each reserved for designating configuration packets. Accordingly, the determination in step S1404 of whether the 
packet is a configuration packet 1 800 is performed by detecting whether the packet contains a protocol-specific "stamp" 

10 (such as a predetermined socket for IPX/SPX, a predetermined port for TCP/IP, or a predetermined DDP type for 
AppleTalk) identifying it as a configuration packet. In other words, it is determined whether the packet is addressed to 
any of the predetermined socket, port, or DDP type. If the packet does not contain any of the predetermined addresses, 
flow advances to step S1405 in which the packet data is serviced, and then flow advances to step S1406 to continue 
with other processing. 

is |f it is determined in step S1404 that the protocol stack does not want the packet, e.g., the packet is addressed to 

one of the predetermined addresses, flow advances to step Si 407 in which the packet is routed to pre-scanning pro- 
gram 84. Flow then advances to step S1412 shown in Figure 14(b). Thus, configuration packets are routed to pre- 
scanning program 84/configurator if (a) no protocol stack is bound for the frame type used by the packet, or (b) all 
protocol stacks bound to the frame type reject the packet (based on a port, socket, DDP type, etc., to which the packet 

20 is addressed) . 

As mentioned above, the packet is routed to pre-scanning program 84 in step S1408 if it is determined by LSL 
187 in step S1402 that a protocol stack is not loaded for the protocol used by the packet. Since in the preferred em- 
bodiment pre-scanning program 84 does not de-register frame types which may be used by a protocol for which no 
frame type is assigned, as discussed above, all possible frame types on LAN 1000 are bound to a loaded protocol 

25 stack and/or pre-scanning program 84. Accordingly, a configuration packet 1800 can be received and processed even 
if it is sent by a device using a protocol and frame type for which NIB 50 has no loaded protocol stack. 

After the packet is routed to pre-scanning program 84 in step S1408, flow advances to step S1409 in which a 
determination is made whether the packet is addressed to the predetermined socket, port, or DDP type. This step is 
like step S1404 discussed above. If the packet is not addressed to one of the predetermined addresses used to des- 

30 ignate a configuration packet 1800, flow advances to step S1410 in which the received frame type is assigned to a 
protocol as in steps S807 through S810, and flow advances to step S1411 to continue with other processing. If it is 
determined in step S1409 that the packet is a configuration packet 1800, i.e., it is addressed to the predetermined 
socket, port, or DDP type, then flow advances to step S1412. 

In step S1412, a validation stamp 1804 which is part of the data 1803 of the configuration packet 1800 is checked 

35 to confirm that the configuration packet is valid. The validation stamp 1804 is an optional feature for added security 
which may be omitted. The validation stamp is preferably a sequence of alphanumeric characters such as an abbre- 
viation of the software provider's name. Alternatively, the validation stamp can be a code sequence of characters. If 
the validation stamp is not correct, the process skips ahead to step S1 41 5 to continue with other processing. If a correct 
validation stamp is present, flow proceeds to step S1413 in which a determination is made whether the configuration 

40 packet is a query packet 1810. Figure 15(b) shows the format of a query packet 1810, and Figure 15(c) shows the 
format of a set packet 1815. Both query packet 1B10 and set packet 181 5 have a set/query field 1805 in data 1803 of 
the packet. This field preferably has just one bit that is 1 if the packet is a set packet and is 0 if the packet is a query 
packet. As shown in Figure 15(b), set/query field 1B05 is the last item in query packet 1815. 

If the packet is a query packet, flow advances to step S1414 in which a response packet 1820 is sent. Figure 15 

45 (d) shows the format of response packet 1 820. Response packet 1 820 includes frame header information 1 806, protocol 
data 1 807, and response data 1 808. Frame header information 1 806 and protocol data 1 807 can be formed by swapping 
source and destination data in query packet 1810, to send response packet 1B20 back to the device that sent query 
packet 1810. Response data 1808 indicates trie protocol stacks that are currently loaded, and the frame type assign- 
ments for each loaded protocol stack. This data can be obtained, for example, from configuration file 75 or from LSL 

50 1 87. After sending the response packet, flow proceeds to step S1 41 5 to continue with other processing. In the preferred 
form, a query packet is received first, before any set packet, so that the current configu ration information can be provided 
to a user, e.g., the system administrator, who wishes to change a protocol or frame type configuration. 

If the received packet is not a query packet, it is deemed to be a set packet and flow advances to step S1416. Set 
packet 1815 includes configuration data 1809 as shown in Figure 15(c). Configuration data 1809 preferably includes 

55 an indication for each protocol stack of whether that stack should be loaded and includes a frame type to be used with 
each loaded protocol stack. Configuration data 1809 may also include other information, such as data identifying the 
media type or an IP address which is a software defined address similar in concept to the hardware defined MAC 
address. In step S1416, configuration data 1809 is used to alter the configuration information in configuration file 75. 
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Flow then advances to step S1417. 

In step S1417, a determination is made whether an immediate re-boot is desired. This determination is made 
based on re-boot data 1811 in data 1803 of set packet 1815. Re-boot data 1811 is preferably a one bit field which is 
1 when immediate re-boot is desired and is 0 otherwise. If immediate re-boot is desired, flow advances to step S141B 
in which the initialization process of Figure 8 is reexecuted using the altered configuration information in configuration 
file 75. Flow then advances to step S1415 to continue other processing. 

If re-boot data 1811 indicates that an immediate re-boot is not desired, flow proceeds from step S1417 to step 
SI 41 5 to continue other processing. The altered configuration information will then be used in the initialization process 
the next time NIB 50 is powered-up or re-booted. It should be noted that, in some cases, the configuration of NIB 50 
can be changed based on the altered configuration information without executing the initialization process. For example, 
"irtrre~a1teTed"conf(gu ration informatTon~merely requires - ^ e _ toading~of~an additional protocol slack that is~noratreaaV 
loaded, it is possible to load that protocol stack into DRAM without reinitializing the device. 

As described above, LSL 187 sends packets to pre-scanning program 84 if any appropriate protocol stack that 
has been loaded declines the packet because the packet is addressed to a predetermined socket, port, or OOP type. 
Thus, pre-scanning program 84 can receive a configuration packet at any time after it has been loaded and registered 
with LSL 187, whether or not any protocol stacks have been loaded. This means that a configuration packet can be 
received and used to alter the configuration information when the initialization process of Figure 8 has executed only 
partly, for example through step S805, and before any protocol stacks are loaded. On the other hand, a configuration 
packet may be received and processed long after the initialization process of Figure 8 has completed execution. 

As described above, the configurator feature has the ability to handle a configuration packet having any protocol 
and frame type combination, even if the network device is not configured to send and receive packets having that 
protocol/frame type combination. 

Figure 1 6 is a flow diagram showing a process for transmitting new configuration information to NIB 50 from another 
network device, such as computer 1500, via LAN 1000. Typically, at least one networked computer runs software that 
allows it to obtain and display information regarding other devices on the network. For example, Novell NetWare may 
be running on a PC under an fPX/SPX protocol. According to the present invention, a software program runs on a 
computer and extends the functions of NetWare software. The version of the program, called MPINIT, that runs on a 
DOS-based PC using an IPX/SPX protocol is a DOS MPINIT There are other versions of MPINIT for other platforms. 
Thus, there is a UNIX MPINIT that runs on a UNIX-based system using a TCP/IP protocol and a Macintosh MPINIT 
that runs on a Macintosh-based system using an AppleTalk protocol. 

One extended function that MPINIT provides is a menu-selected option to set or query the configuration information 
of a particular network device. In step S1601 of Figure 16, a MAC address of a device is input along with a command 
to QUERY or SET the configuration information for the designated device. This may not be necessary for some network 
configurations where the NIB can advertise its presence using a protocol and frame that the computer is set up for. 
Flow then proceeds to step S1602 in which a determination is made whether the command is a SET command. If the 
command is not a SET command, flow advances to step S1603. If the command is a SET command, flow advances 
to stepS 1607. 

In step S1603, since a SET command was not detected in step S1602, processing is performed for a QUERY 
command. In a preferred embodiment, an initial query packet is sent by MPINIT without a user's specific request, in 
order to present a list of current NIB configuration information. The user may then cause a SET packet to be issued 
as desired. A query packet 1810 is formed using the MAC address input in step SI 601 as the destination address 
information. Flow then advances to step SI 604 in which query packet 1810 is transmitted to the designated network 
device, NIB 50 in this case, via LAN 1000 using whatever protocol and frame type is in use by computer 1500 executing 
MPINIT, which in the case of a DOS-based PC is IPX/SPX over the assigned frame type. In step S1605, the process 
waits until a response packet 1820 is received. When response packet 1820 is received, flow advances to step S1606 
in which the current configuration information contained in response packet 1820 is displayed on a display device of 
the computer. Flow then returns to step S1601 to await another command. 

In step S1607, if a SET command is detected in step SI 602, new configuration information is input. The new 
configuration information can be input by keyboard and, if current configuration information of a designated device is 
baing displayed in response to a QUERY command, the new configuration information can be input by editing the 
displayed information. Alternatively, the new configuration information can be input from a configuration file in computer 
1500. After inputting the new configuration information, flow advances to step S1608. 

In step S1608, a set packet 1815 is formed using the MAC address input in step S1601 and the new configuration 
information input in step SI 607. MPINIT can be configured to set re-boot data 1811 to always request immediate re- 
boot by default, or a user can be prompted by the software to input re-boot data 1811. Flow then advances to step 
S1609 in which set packet 1815 is transmitted to the designated network device with the protocol used by computer 
1500 executing MPINIT Flow then returns to step S1601 to await another command. 

As described above, pre-scanning program 84 processes packets in all frame types allowed on LAN 1000 in the 
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most preferred embodiment. Accordingly, a Macintosh computer using AppleTatk can send a configuration packet to 
NIB 50 even if NIB 50 only has protocol stacks loaded for IPX/SPX and TCP/IP protocols. Pre-scanning program 84 
will receive and process the configuration packet, and NIB 50 can be reconfigured to load an AppleTalk protocol stack 
and communicate with the Macintosh computer. 
5 Further, the present invention is not limited to use only with peripherals. A configuration packet 1800 can also be 

sent to a computer if the computer includes the appropriate software to detect and process the configuration packet 
according to the above-described process. In this manner, a system administrator's computer can reconfigure other 
computers on LAN 1000 if a frame type used for a protocol is changed. 

' 1Q [4. Other Embodiments] 



Although a preferred form of the present invention is described above in the context of NIB 50 for interfacing a 
digital copier to LAN 1000, the present invention is applicable to other network interface devices for interfacing other 
peripherals, such as printers, scanners, and-facsimile devices, to LAN 1000. For example, the present invention can 
is be used with the Network Expansion Board (NEB) described in U.S. Patent No. 5,323,393 entitled "Method And Ap- 
paratus For Obtaining And For Controlling The Status Of A Networked Peripheral". 

That patent discloses a PRESCAN module which performs autosensing of frame types, then terminates and causes 
protocol stacks to load. That PRESCAN module can be modified to perform the configurator function described in 
connection with Figure 14, if the PRESCAN module is also modified to remain resident after completing its pre-scanning 
20 operation. 

Further, the present invention can be used with Network Expansion Board disclosed in U.S. Patent Application S. 
N. 08/336,062, entitled "Network Protocol Sensor" (EP Application 95307708.B) 

The PRETASK module disclosed in that application remains resident after completing its pre-scanning operation. 
Therefore, PRETASK need only be modified to perform the configurator function described with respect to Figure 14. 

25 in addition, the present invention can be used with the Network Expansion Device disclosed in U.S. Patent Appli- 

cation No. 08/489,283, (PCTAJS/96/10058) and entitled "Network Device Which Responds To Status Changes Of Its 
Installed Peripheral By Generating A Testpage". The PRESCAN software module disclosed in that application would 
require modification -like the above-mentioned PRESCAN module. Further, that device has no NVRAM. Accordingly, 
both the software modules and configuration information must be stored in EPROM. 

30 While the present invention has been described with respect to a particular illustrative embodiment, it is to be 

understood that the invention is not limited to the above described embodiment and that various changes and modifi- 
cations may be made by those of ordinary skill in the art without departing from the scope of the invention. 



Claims 

1. A method for dynamically determining a media type of a local area network (LAN) to which a network device is 
connected, said method comprising the steps of: 



executing a network interface driver software module which is the lowest level of software to communicate 
with the LAN and which handles the sending and receiving of communication packets to and from the LAN by 
appending or stripping off packet frame headers, wherein the network interface driver software module has 
one or more logical boards for processing communication packets having different respective frame types and 
has one or more configuration tables, each respectively associated with one of the logical boards, which each 
include a frame type identifying value that identifies a combination of frame type and media type for packets 
processed by the corresponding logical board, and wherein the network interface driver has a service routine 
accessible via an entry point; 

executing one or more protocol stack modules for processing packets that use different respective protocols; 
executing a multiplexer software module which interfaces between the network interface driver software mod- 
ule and the one or more protocol stack modules and which routes packets from the network interface driver 
software module to the respective protocol stack modules according to the protocol used by the packets; 
obtaining the entry point of the network interface driver service routine via the multiplexer software module; 
obtaining a location for one of the configuration tables via the service routine; 
reading the frame type identifying value in the one configuration table; and 

determining the network media type by comparing the frame type identifying value read from the one config- 
uration table to one or more values that correspond to a predetermined media type. 

2. A method according to Claim 1 , wherein the network interface driver software module has an 802.3 logical board 
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that processes packets having an 802.3 frame type and the corresponding configuration table has an identifying 
value of 5 for an Ethernet media type and an identifying value of 4 for a token ring media type, and wherein the 
media type is determined by reading the identifying value from the configuration table for the 802.3 logical board 
and comparing the identifying value that is read to the value 5. 

A method according to Claim 1 , wherein the arrangement of logical boards for different frame types in the network 
interface driver software module is unknown to the protocol stack modules, and wherein the media type is deter- 
mined by reading the identifying value from the configuration table for one logical board and comparing the iden- 
tifying value that is read to each possible value corresponding to an Ethernet media type. 



A method according to Claim 1 , wherein the arrangement oflogicaiDoarcis lor aiffereni frame typesintherretwork 
interface driver software module is unknown to the protocol stack modules, and wherein the media type is deter- 
mined by reading the identifying value from the configuration table for one logical board and comparing the iden- 
tifying value that is read to each possible value corresponding to a token ring media type. 

A network interface device which interfaces with a local area network (LAN) and which dynamically determines a 
media type of the LAN to which the network device is interfaced, said network interface device comprising: 

a storage device that stores (i) a network interface driver software module which is the lowest level of software 
to communicate with the LAN and which handles the sending and receiving of communication packets to and 
from the LAN by appending or stripping off packet frame headers, wherein the network interface driver software 
module has one or more logical boards for processing communication packets having different respective 
frame types, and wherein the network interface driver software module has a configuration table for each of 
the one or more logical boards and each configuration table includes a frame type identifying value that iden- 
tifies a combination of frame type and media type for packets processed by the corresponding logical board, 
(ii) one or more protocol stack modules for processing packets that use different respective protocols, and (iii) 
a multiplexer software module which interfaces between the network interface driver software module and the 
one or more protocol stack modules and which routes packets from the network interface driver software 
module to the respective protocol stack modules according to the protocol used by the packets; and 
a processor that (i) executes the network interface driver software module, the multiplexer software module, 
and the one or more protocol stack modules, (ii) reads the frame type identifying value in one of the configu- 
ration tables, and determines the network media type by comparing the frame type identifying value read from 
the one configuration table to one or more values that correspond to a predetermined media type. 

A network interface device according to Claim 5, wherein the network interface driver software module has an 
802.3 logical board that processes packets having an 802.3 frame type and the corresponding configuration table 
has an identifying value of 5 for an Ethernet media type and an identifying value of 4 for a token ring media type, 
and wherein said processor determines the media type by reading the identifying value from the configuration table 
for the 802.3 logical board and comparing the identifying value that is read to the value 5. 

A network interface device according to Claim 5, wherein the arrangement of logical boards for different frame 
types in the network interface driver software module is unknown to said processor, and wherein said processor 
determines the media type by reading the identifying value from the configuration table for one logical board and 
comparing the identifying value that is read to each possible value corresponding to an Ethernet media type. 

A network interface device according to Claim 5, wherein the arrangement of logical boards for different frame 
types in the network interface driver software module is unknown to said processor, and wherein said processor 
determines the media type by reading the identifying value from the configuration table for one logical board and 
comparing the identifying value that is read to each possible value corresponding to a token ring media type. 
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(54) Dynamically determining network media type 



(57) A method for dynamically determining a media 
type of a local area network (LAN) to which a network 
device is connected. A network interface driver software 
module is executed which is the lowest level of software 
to communicate with the LAN and which handles the 
sending and receiving of communication packets to and 
from the LAN by appending or stripping off packet frame 
headers. The network interface driver software module 
has one or more logical boards for processing commu- 
nication packets having different respective frame types 
and has one or more configuration tables, each respec- 
tively associated with one of the logical boards, which 
each include a frame type identifying value that identi- 
fies a combination of frame type and media type for 
packets processed by the corresponding logical board. 
The network interface driver software module also has 
a service routine which can be accessed via an entry 
point. One or more protocol stack modules are executed 
for processing packets that use different respective pro- 
tocols, and a multiplexer software module is executed 
which interfaces between the network interface driver 
software module and the one or more protocol stack 
modules and which routes packets from the network in- 
terface driver software module to the respective protocol 
stack modules according to the protocol used by the 
packets. The entry point of the network interface driver 
service routine is obtained via the multiplexer module. 
A location of one of the configuration tables is then ob- 
tained via the service routine. The frame type identifying 
value in the one configuration table is then read, and the 
network media type is determined by comparing the 
frame type identifying value read from the one configu- 



ration table to one or more values that correspond to a 
predetermined media type. 
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